Globe view marker support #11556
Globe view marker support #11556
Conversation
SnailBones
added
3d 📐
skip changelog
… pitch-alignment:map in globe without change to 2d behavior
There was a problem hiding this comment.
One more pass of review with the following notes:
- I suggest to disable occlusion for markers to remove the extraneous 100km check concerning Globe view marker support #11556 (comment)
- I think we can cleanup the logic around
locationPoint3DAPI to remove the extraneous globe branching: Globe view marker support #11556 (comment) - Question: Do you know what could be the reason of this slight precision difference when crossing the threshold mercator/globe? The difference is large enough that it could be pointing at an incorrect location. I also wonder if that's the limitation you mentioned in the description around the transition support:
marker-jump.mov
marker-jump2.mov
|
Thanks for the review @karimnaaji!
I'm not sure I understand what you're suggesting here. Occlusion on globe is an intended feature that I've added to this PR, and disabling it makes markers visible on the far side of the globe. The 100km check could be removed with a different occlusion algorithm, EDIT: Thinking more about this, we want to hide markers behind the globe while only making ones hidden behind terrain transparent. So it actually makes sense to handle each in turn, and it's worth investigating other methods to improve performance, accuracy, or simplify the code of globe occlusion.
Yes, that's the issue I mention in the description. I share some ideas on how to solve the issue there, IMO the solution is out of scope for this PR. |
There was a problem hiding this comment.
👍 Nice work @SnailBones .
Let's follow up on simplifying occlusion checks for globe, as it should end up to only looking at the dot product sign between the camera forward direction and center-marker location vectors, similarly to how it's done here. This would simplify those checks and remove the extraneous 100kms padding introduced due to the lack of accuracy of the method, which in that case is well suited for terrain and not as much for globe.
Closes https://github.com/mapbox/gl-js-team/issues/373
Default viewport alignment (
pitchAlignment: viewport&rotationAlignment: viewport):marker-viewport-viewport.mov
Map alignment(
pitchAlignment: map&rotationAlignment: map):marker-map-map-2.mov
Two small issues with the current approach:
During the globe to Mercator transition, markers are placed as if the map was still a full globe, resulting in incorrect placement and a jump in position when the map crosses the threshold into pure Mercator at high pitch. Fixing this issue would require changing the behavior of Globe.locationPoint to account for the transition, which probably would amount to a change in the globe matrix calculation. This change should also improve the behavior of various API calls during the transition. This fix is out of scope for this PR, but the benefits of a more accurate transformation matrix mean that this is worth investigating. Alternatively, these issues could also be minimized by moving the transition to a higher zoom.
With map alignment, the marker's angle can appear slightly incorrect, particularly when a marker is near to or on the horizon. This could be resolved in the future by a more accurate marker placement model that transforms the marker according to its 3d position on the globe (as opposed to the current approximation handling x + y rotations separately from z rotations).
Both of these issues are subtle enough that I don't see them as blockers to this PR.
Launch Checklist
@mapbox/map-design-team@mapbox/static-apisif this PR includes style spec API or visual changes@mapbox/map-design-team